Various organizations make use of enterprise resource planning (ERP) software architectures to provide an integrated, computer-based system for management of internal and external resources, such as for example tangible assets, financial resources, materials, customer relationships, and human resources. In general, an ERP software architecture is designed to facilitate the flow of information between business functions inside the boundaries of the organization and manage the connections to outside service providers, stakeholders, and the like. Such architectures often include one or more centralized databases accessible by a core software platform that consolidates business operations, including but not limited to those provided by third party vendors, into a uniform and organization-wide system environment. The core software platform can reside on a centralized server or alternatively be distributed across modular hardware and software units that provide “services” and communicate on a local area network or over a network, such as for example the Internet, a wide area network, a local area network, or the like.
As part of the installation process of the core software platform on computing hardware owned or operated by the organization, one or more customized features, configurations, business processes, or the like may be added to the default, preprogrammed features such that the core software platform is configured for maximum compatibility with the organization's business processes, data, and the like.
The core software platform of an ERP software architecture can be provided as a standalone, customized software installation that runs on one or more processors that are under the control of the organization. This arrangement can be very effective for a large-scale organization that has very sophisticated in-house information technology (IT) staff and for whom a sizable capital investment in computing hardware and consulting services required to customize a commercially available ERP solution to work with organization-specific business processes and functions is feasible. Smaller organizations can also benefit from use of ERP functionality. However, such an organization may lack the necessary hardware resources, IT support, and/or consulting budget necessary to make use of a standalone ERP software architecture product and can in some cases be more effectively served by a software as a service (SaaS) arrangement in which the ERP system architecture is hosted on computing hardware such as servers and data repositories that are maintained remotely from the organization's location and accessed by authorized users at the organization via a thin client, such as for example a web browser, over a network.
In a software delivery configuration in which services provided to each of multiple organizations are hosted on a dedicated system that is accessible only to that organization, the software installation at the dedicated system can be customized and configured in a manner similar to the above-described example of a standalone, customized software installation running locally on the organization's hardware. However, to make more efficient use of computing resources of the SaaS provider and to provide important performance redundancies and better reliability, it can be advantageous to host multiple tenants on a single system that includes multiple servers and that maintains data for all of the multiple tenants in a secure manner while also providing customized solutions that are tailored to each tenant's business processes.
Such an approach can introduce several challenges. As one example, with a multi-tenant approach, lifecycle events such as an application server going down synchronously affect customers using the system. In addition, for convention upgrade procedures, downtime is required which in turn requires that all customers have a simultaneous downtime. Such an arrangement is not always suitable for all customers, especially when they are geographically dispersed across multiple time zones (e.g., Saturday night in Europe is daytime in USA or Asia, and Sunday is a working day in the Middle East, etc.). Therefore, to avoid such issues, dedicated systems are needed per region, which increases costs. Moreover, even if such customers are in the same time zone, negotiations might have to occur amongst multiple customers when the downtime will be extensive. Such a scenario can quickly become complicated when there are multiple parties each with differing agendas.
For certain tasks during an upgrade, the runtime depends on the data volume, the number of entries in the tables. Thus for larger systems, downtime becomes larger. In a multi tenant system, not only one customer enters data, but several (e.g. up to 100) so that the data volume is larger than the volume of a single customer system. To a certain extent, the larger volume can be processed with stronger hardware and more processes. However, such hardware and processes can be costly.